嗨，大家好，我是洧杰，好久沒參加鐵人邦了！

之前我在這裡寫過《菜鳥工程師必修的 30 堂溝通課》，分享工程師在工作上，該怎麼跟主管、PM、設計師與後端溝通。這次想說回來重新溫習一下，連續 30 天把腦袋裡的東西整理成文章，再跟大家一起交流的感覺。

隔了這麼久又回來寫，蠻有一種「好，該把生鏽的寫文肌肉重新練起來了」的感覺 XD

這次要分享的題目是：《從前後端踏上 AWS 雲端架構勇者之路》。

以前的系列聊人跟人怎麼合作，這次想帶大家看看，一個網站背後的主機、網路、資料庫與各種服務，究竟是怎麼接在一起的。

程式在我電腦會跑，然後呢？

以前寫前端時，我比較在意的是畫面有沒有正常、資料有沒有接起來、功能能不能依照預期運作。但接觸雲端後會發現，要照顧的東西突然多了不少。

假設你今天做完一個網站，前端畫面正常，後端 API 也會回資料，滿懷信心地準備讓別人使用，接著就冒出一串問題：

「程式要放在哪一台主機上，別人才連得到？」

「使用者上傳的照片要存哪裡？重新部署會不會不見？」

「資料庫要開給誰連？總不能知道地址的人都能進來吧？」

「網站如果半夜掛了，我是自己先發現，還是等使用者來跟我說？」

原本覺得功能做完就可以收工，結果往後看，還有一整排事情在等你....冏

所以這 30 天，我想用前後端工程師的視角，帶大家理解這些事情背後的觀念。從自己熟悉的程式出發，慢慢看懂它放上雲端後，每一個環節在負責什麼。

先攤開一張圖：一個網站背後有哪些東西？

這 30 天，我想依照下面這張架構圖，和大家分享一個網站放上 AWS 後，背後會有哪些東西，以及它們各自負責什麼。

我們會用一個常見的網站情境來看：使用者可以登入、查詢資料、上傳照片，完成某個操作後，系統會寄一封通知信。這些看起來很平常的功能，背後其實就串起了主機、網路、資料庫與各種服務。

一個網站背後的 AWS 架構：網站入口、應用主機、私有資料庫、照片儲存，以及部署與監控服務的分工 · 點圖查看原始尺寸

如果你現在看到 EC2、S3、RDS 這些名字，覺得「嗯……好像都看過，但不知道它們在幹嘛」，也沒關係，現在看不懂很正常

接下來我會一天天分享，每天拆開其中一小塊，從程式放在哪裡、資料怎麼保存，到使用者如何連進來，以及出問題時該看哪裡，慢慢把它們串在一起。

希望等到第 30 天，再回頭看這張圖時，你會發現：「哦，原來這些服務是這樣搭配的！」

這 30 天，我希望你帶走什麼？

我希望你讀完後，再看到一張雲端架構圖，能夠沿著請求把它讀懂。

知道程式在哪裡執行、資料放在哪裡、誰可以連進來；碰到網站打不開、圖片讀不到或資料庫連不上時，也能先縮小問題範圍，而不是看到錯誤就把所有權限全部打開。

文章會逐步帶到下面這些方向，先從資源放在哪個 Region、如何判斷 AZ 的故障範圍開始：

• 區域、帳號與操作環境。 從 Region 與 AZ 開始，再認識身分、權限、費用與 Linux。
• 網路與主機。 把 IP、Port、DNS、VPC、Security Group 與 EC2 的關係串起來。
• 資料、檔案與郵件。 了解 S3、RDS、SES 各自負責什麼，以及使用時要考慮哪些限制。
• 容器與部署。 理解 Docker、ECR、執行環境與 IAM Role，看看程式從開發到執行經過哪些階段。
• 網站入口與版本更新。 談 Nginx、DNS、HTTPS，還有改版時為什麼要考慮回退與資料相容性。
• 監控、排錯與資源生命週期。 練習從現象找線索，也理解服務停用之後還有哪些東西需要處理。

每篇我都會搭配圖片，把當天講的事情畫出來。尤其網路與服務關係，光看一長串文字真的很容易迷路，有圖比較容易知道「現在到底走到哪裡了」。

另外，我也會針對當天分享的觀念，特別設計一些題目，和大家來場「靈魂拷問」跟腦力激盪 XD

有時候看文章會覺得「嗯嗯，懂了」，但換個情境問你：「那這時候你會怎麼做？為什麼？」可能就會突然卡住。希望透過這些題目，讓大家練習用自己的話說明想法，也確認自己是不是真的理解這個觀念。

如果你會寫一點前端或後端，也想了解雲端架構，歡迎一起看。這個系列會以概念、圖解和常見情境來說明，你不用先準備一套專案，也能跟著理解每個元件的用途。

像是今天這張圖，只有一台應用主機與一台資料庫，它就會有單點故障的限制。隨著我們對每個環節更熟悉，也會開始問：「如果這一台壞了呢？」「要改善它，又得付出哪些成本？」能夠開始思考這些取捨，就是往雲端架構前進的一步。

好久沒在鐵人邦連載了，這次也想藉著寫文，把自己的理解重新整理一次。如果你有不同的想法，或哪個地方看不懂，也歡迎留言交流。

明天先從「網站放上雲端，是放在哪裡？」聊起，帶大家認識 AWS Region。一起踏上這趟 AWS 雲端架構勇者之路吧 :D